COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Dialnet memo #6
C00004 00003			      Why 254. Channels are Better than 1
C00010 ENDMK
C⊗;
Dialnet memo #6
SAILON the deep blue sea

















		      Why 254. Channels are Better than 1.

				  Mark Crispin

				    3/15/78





























     These protocols are being developed as  part of the Dialnet project at  the
Stanford University Artificial  Intelligence Laboratory supported  by NSF  grant
MCS 77-02080  with John  McCarthy  as Principal  Investigator.  The  project  is
described  in   a   paper   available   online  at   ARPAnet   host   SU-AI   as
DIALNE.MEM[DLN,MRC] (Dialnet Memo #1).

     This is WHY254.MEM[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
		      Why 254. Channels are Better than 1

     From the early design  of Dialnet, I had  envisioned the need for  allowing
multiple channels in the line transmission  protocol.  However, a great deal  of
disagreement came up over that question.  There was a good deal of opposition to
having multiple  channels, partially  because I  had originally  proposed  their
usage for the wrong reason; to have multiple processes use the same dial line.

     However, just because multiple channels could  be used for a bad idea  does
not mean in itself that multiple channels are a bad idea.  After a good deal  of
debate, it was agreed to allow a single  byte in the packet header to be  marked
as "reserved", although its purpose was obvious.  There was, however,  continued
opposition to this byte ever being used for that purpose.

     A need has come up for multiple  channels, however.  The problem has to  do
with data vs. control channels.  Under the current scheme, in the mail and  file
transfer protocols control  has to  share the  single channel  with data.   This
means that while data is being  sent, no control protocol negotiations may  take
place.  Control and data transmissions must be totally synchronous.

     This disallows  several desirable  capabilities.  For  example, this  means
there is no way in which status reports on the progress of the data transmission
may be  sent back  to the  user.  It  means the  user has  no facility  to  send
additional commands, or to inquire about the progress of the transmission, or to
abort the data transfer.

     There is  another,  even more  serious  problem.   In both  mail  and  file
transfer, certain syntax  constructions are  used in  the control  parts of  the
protocol (see McCarthy, "Format for Non-Interactive Tertiary Protocols", Dialnet
memo #4).   This  forces  quoting  conventions  to be  used  on  data  which  is
transmitted over  a control  channel.   The overhead  involved  in this  may  be
considerable.

     The solution is  clear; data and  control should be  on separate  channels.
This prevents interference  between the  two, and in  particular allows  control
protocol negotiations while data  transfer is in  progress without aborting  the
data transfer.

     Consequently, I am defining byte 1 of  the packet header to be the  channel
number.  Channels 226 and 227 are illegal (because of framing problems) and  can
not be used.  Therefore, there are 254. legal channels.

     To avoid future problems, I  shall establish some conventions now.   First,
since the intent of multiple channels is not to implement multiple processes,  I
have defined channel 0 as  the control channel.  ICP's  are done on the  control
channel only.  For protocols such as the  TELNET protocol channel 0 will be  the
only one  used.  Second,  since there  probably  will be  an eventual  need  for
channel  genders,  I   will  define  odd-numbered   channels  as  channels   for
server-to-user data transactions, and even-numbered channels for  user-to-server
data transactions.  Therefore, for the present hairiest case only channels 0, 1,
and 2 are used.

     These definitions will be made in the ICP protocol document and not in  the
Host-host protocol, since channels are  invisible to the host-host protocol.   I
believe this allows  for future extension  to how  channels are to  be used,  as
unanticipated needs might come up.